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

[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?).

Post by 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.

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

Philippe

[Shane McCarron]

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.

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?).

Post by 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.

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

[Tab Atkins Jr.]

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

[Philippe Le Hegaret]

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

Post by 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

[Martin J. Dürst]

Post by Philippe Le Hegaret
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.

[Philippe Le Hegaret]

Post by Martin J. Dürst

Post by Philippe Le Hegaret
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

[fantasai]

Post by Martin J. Dürst

Post by Philippe Le Hegaret
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 :)
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

[fantasai]

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