Stylesheet Ordering Requirement

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Stylesheet Ordering Requirement

fantasai
Can we drop the requirement that all styles must be before
the link to the official W3C styles? While we do want to
enforce consistency, and keep people from inappropriately
overriding site-wide styling, this rule just creates the
need for inappropriate specificity hacks when things do
need to be overridden.

[And of course, if there are problems with the W3C styles
that are getting in your way as you're styling your spec,
please file a bug at https://github.com/w3c/tr-design/issues
instead of trying to work around the problem ]

~fantasai

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

Philippe Le Hegaret
We certainly could but then, that's one less consistency that we'd be
able to enforce, ie such as color of the links, etc.

Knowing that folks always have a tendency to argue about colors and
shapes, we will get divergences and we won't attempt to manually enforce
consistency. That's the reason why this rule was put in place to start
with (remember the link color on the SVG specs?).

On 05/16/2016 06:41 PM, fantasai wrote:
> Can we drop the requirement that all styles must be before
> the link to the official W3C styles? While we do want to
> enforce consistency, and keep people from inappropriately
> overriding site-wide styling, this rule just creates the
> need for inappropriate specificity hacks when things do
> need to be overridden.

... which has the nice side effect that few attempt to do such thing.

Philippe

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

Shane McCarron-6
There are really good A11Y reasons to ensure that things like colors, fonts, layouts, etc. I wouldn't want specs to do something silly that would reduce their A11Y.

On Thu, May 19, 2016 at 11:17 AM, Philippe Le Hegaret <[hidden email]> wrote:
We certainly could but then, that's one less consistency that we'd be able to enforce, ie such as color of the links, etc.

Knowing that folks always have a tendency to argue about colors and shapes, we will get divergences and we won't attempt to manually enforce consistency. That's the reason why this rule was put in place to start with (remember the link color on the SVG specs?).

On 05/16/2016 06:41 PM, fantasai wrote:
Can we drop the requirement that all styles must be before
the link to the official W3C styles? While we do want to
enforce consistency, and keep people from inappropriately
overriding site-wide styling, this rule just creates the
need for inappropriate specificity hacks when things do
need to be overridden.

... which has the nice side effect that few attempt to do such thing.

Philippe




--
Shane McCarron
Projects Manager, Spec-Ops
Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

Tab Atkins Jr.
On Thu, May 19, 2016 at 9:49 AM, Shane McCarron <[hidden email]> wrote:
> There are really good A11Y reasons to ensure that things like colors, fonts,
> layouts, etc. I wouldn't want specs to do something silly that would reduce
> their A11Y.

Like fantasai said, the ordering requirement does not enforce this in
any way; preceding stylesheets can override whatever they want by
making sure the specificity is high enough.  This sort of requirement
is only enforceable socially, not technologically.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

Philippe Le Hegaret
In reply to this post by fantasai
One other thought on this topic:

I wonder if this issue is a side effect of adding more rules in the base
style sheet. Having more rules has the nice effect that we can factorize
and reuse a lot more. It provides an off-the-shelf set of rules. etc. I
haven't heard anyone complaining about the increase of rules in the base
style sheet.

But, it also means that the pubrules requirement is increasing, ie we're
making it hard to change rules around table layout, pre, code, nav,
ol.algorithm, example, etc. Those things were never intended to be the
target of the pubrules checker.

In other words, from the perspective of pubrules, there is a set of
rules that we care in the base style sheet while there is a set that we
don't mind if the authors start modifying them. Since we've been
increasing the second set, the rule is getting more in the way.

Is that correct?

Philippe


On 05/16/2016 06:41 PM, fantasai wrote:

> Can we drop the requirement that all styles must be before
> the link to the official W3C styles? While we do want to
> enforce consistency, and keep people from inappropriately
> overriding site-wide styling, this rule just creates the
> need for inappropriate specificity hacks when things do
> need to be overridden.
>
> [And of course, if there are problems with the W3C styles
> that are getting in your way as you're styling your spec,
> please file a bug at https://github.com/w3c/tr-design/issues
> instead of trying to work around the problem ]
>
> ~fantasai
>

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

Martin J. Dürst


On 2016/05/20 22:57, Philippe Le Hegaret wrote:

> One other thought on this topic:
>
> I wonder if this issue is a side effect of adding more rules in the base
> style sheet. Having more rules has the nice effect that we can factorize
> and reuse a lot more. It provides an off-the-shelf set of rules. etc. I
> haven't heard anyone complaining about the increase of rules in the base
> style sheet.
>
> But, it also means that the pubrules requirement is increasing, ie we're
> making it hard to change rules around table layout, pre, code, nav,
> ol.algorithm, example, etc. Those things were never intended to be the
> target of the pubrules checker.
>
> In other words, from the perspective of pubrules, there is a set of
> rules that we care in the base style sheet while there is a set that we
> don't mind if the authors start modifying them. Since we've been
> increasing the second set, the rule is getting more in the way.
>
> Is that correct?

Assuming that's correct, then what about separating the rules we care
and the rules we don't care that much into two different files, and
require only the former to be last?

Regards,   Martin.

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

fantasai
In reply to this post by Philippe Le Hegaret
On 05/20/2016 06:57 AM, Philippe Le Hegaret wrote:

> One other thought on this topic:
>
> I wonder if this issue is a side effect of adding more rules in the base style sheet. Having more rules has the nice effect
> that we can factorize and reuse a lot more. It provides an off-the-shelf set of rules. etc. I haven't heard anyone complaining
> about the increase of rules in the base style sheet.
>
> But, it also means that the pubrules requirement is increasing, ie we're making it hard to change rules around table layout,
> pre, code, nav, ol.algorithm, example, etc. Those things were never intended to be the target of the pubrules checker.
>
> In other words, from the perspective of pubrules, there is a set of rules that we care in the base style sheet while there is
> a set that we don't mind if the authors start modifying them. Since we've been increasing the second set, the rule is getting
> more in the way.
>
> Is that correct?

The stylesheet documentation more or less says "please feel free
to modify table styling, particularly wrt alignment". Most other
things shouldn't be modified, except maybe the layout of figures
(which are often floated or set into tables or suchlike).

However a number of things need subclassing, and having this
ordering requirement makes that much more awkward than it needs
to be.

~fantasai

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

Philippe Le Hegaret
In reply to this post by Martin J. Dürst
On 05/20/2016 10:18 PM, Martin J. Dürst wrote:

> On 2016/05/20 22:57, Philippe Le Hegaret wrote:
>> One other thought on this topic:
>>
>> I wonder if this issue is a side effect of adding more rules in the base
>> style sheet. Having more rules has the nice effect that we can factorize
>> and reuse a lot more. It provides an off-the-shelf set of rules. etc. I
>> haven't heard anyone complaining about the increase of rules in the base
>> style sheet.
>>
>> But, it also means that the pubrules requirement is increasing, ie we're
>> making it hard to change rules around table layout, pre, code, nav,
>> ol.algorithm, example, etc. Those things were never intended to be the
>> target of the pubrules checker.
>>
>> In other words, from the perspective of pubrules, there is a set of
>> rules that we care in the base style sheet while there is a set that we
>> don't mind if the authors start modifying them. Since we've been
>> increasing the second set, the rule is getting more in the way.
>>
>> Is that correct?
>
> Assuming that's correct, then what about separating the rules we care
> and the rules we don't care that much into two different files, and
> require only the former to be last?

My reluctance for that is that it means we would have 2 files, with one
under particular constraint.

There is also the case that we're increasing the number of requests but
I guess this should be seen as job security for our system folks and the
webperf group :)

In the set of solutions, we could:
1- have two files
2- remove the requirement as formulated and instead make sure check a
lot smarter, such as check the computed style of some of the elements
instead.

I haven't check with Comm to see which rule they care the most.

Philippe

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet Ordering Requirement

fantasai
On 06/08/2016 02:02 PM, Philippe Le Hegaret wrote:

> On 05/20/2016 10:18 PM, Martin J. Dürst wrote:
>> On 2016/05/20 22:57, Philippe Le Hegaret wrote:
>>> One other thought on this topic:
>>>
>>> I wonder if this issue is a side effect of adding more rules in the base
>>> style sheet. Having more rules has the nice effect that we can factorize
>>> and reuse a lot more. It provides an off-the-shelf set of rules. etc. I
>>> haven't heard anyone complaining about the increase of rules in the base
>>> style sheet.
>>>
>>> But, it also means that the pubrules requirement is increasing, ie we're
>>> making it hard to change rules around table layout, pre, code, nav,
>>> ol.algorithm, example, etc. Those things were never intended to be the
>>> target of the pubrules checker.
>>>
>>> In other words, from the perspective of pubrules, there is a set of
>>> rules that we care in the base style sheet while there is a set that we
>>> don't mind if the authors start modifying them. Since we've been
>>> increasing the second set, the rule is getting more in the way.
>>>
>>> Is that correct?
>>
>> Assuming that's correct, then what about separating the rules we care
>> and the rules we don't care that much into two different files, and
>> require only the former to be last?
>
> My reluctance for that is that it means we would have 2 files, with one under particular constraint.
>
> There is also the case that we're increasing the number of requests but I guess this should be seen as job security for our
> system folks and the webperf group :)
>
> In the set of solutions, we could:
> 1- have two files
> 2- remove the requirement as formulated and instead make sure check a lot smarter, such as check the computed style of some of
> the elements instead.
>
> I haven't check with Comm to see which rule they care the most.

Does it need to be an automated check? Couldn't we just say
"Keep styling changes localized to necessary tweaks to content
and preserve stylistic consistency across W3C Technical Reports.
For example, feel free to override table header alignment or
add syntax highlighting classes, but don't modify styling of the
header, ToC, or HTML/BODY margins and font settings."

~fantasai