[whatwg] nostyle consideration
Proposing nostyle in the spirit of noscript
Examples
1) Head Usage
nostyle
meta http-equiv=Refresh content=0;url=/errors/stylerequired.html
/nostyle
2) Body Usage
nostyle
h2Warning: Styles required for correct rendering/h2
/nostyle
The Obvious Push Back
-
Why bother? You can just do this
.nostyle {display: none;}
h2 class=nostyleWarning: Styles required for correct rendering/h2
And yes while that is true and for many situations will work fine, there are
other cases you won't and you can get a sloppy or even bad results because
of rendering engine paths. For example, because style is not applied until
later you have an issue here
h2 class=nostyleimg src=error.gifWarning: Styles required for
correct rendering/h2
The network request happens regardless of situation no assuming images on.
This of course makes the idea of
h2 style=display:none;img src=error.php?style=offWarning: Styles
required for correct rendering/h2
kind of useless.
Obviously detecting style availability is no problem using JavaScript, just
measure some style region or compute a style. However, in the absence of
JavaScript it is actually somewhat of a challenge to detect this case you
have to look for dependent requests as a clue like some style only available
background-image or something.
These corner cases aren't necessarily the main concerns, a serious
motivation for this element is also because of some of the nonsense I am
observing with background-image and content property near abuse by CSS
wonks. It appears that there is a fairly decent sized camp of CSS for
everything and this element might help mitigate some problems stemming from
this. For example, using the content property can be somewhat troubling if
style is removed. For example, consider what happens if you are putting in
field required indicators
input[type=text].required:before {content: (*) }
or for offsite links
a[href^=http://]:after {content:' ( Offsite Link )';}
or any other dynamic insert this way. In my book effort I am seeing
tremendous interest in the design community with such rules. Without style
you lose valuable data and there is no easy recourse to present this
situation at least not one without using JavaScript. At least having
warnings via a nostyle element would be assisitive in informing users that
this isn't quite right and in some cases I might dream up helpful for
accessibility in light of too much CSS abuse.
Just an aside: The content property is the CSS cousin of document.write if
you think about it, useful but problematic.
So given that noscript correctly acts in masking content for user agents
supporting and not for those off or unsupporting, the nostyle element seems
like a quite logical solution for the other technology key client-side tech.
Anyway if this were an acceptable addition, tag syntax would be quite simple
would only have common attributes, pretty basic replication of noscript
prose in the specification. Though of course this is one element that would
require browser changes, no quick simulation with JS.
Comments?
-Thomas Powell
Re: [whatwg] nostyle consideration
On Mon, Jun 15, 2009 at 2:14 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Mon, Jun 15, 2009 at 4:26 PM, Thomas Powelltpow...@gmail.com wrote:
Proposing nostyle in the spirit of noscript
Examples
1) Head Usage
nostyle
meta http-equiv=Refresh content=0;url=/errors/stylerequired.html
/nostyle
2) Body Usage
nostyle
h2Warning: Styles required for correct rendering/h2
/nostyle
The reason that noscript worked is because (IIRC) it was introduced
at the same time as script. All browsers that supported script
also supported noscript. nostyle would cause all legacy user
agents to render the content even if they supported styles just fine.
Yes in the absence of our time machine it seems a bit late doesn't it.
And yes while that is true and for many situations will work fine, there
are
other cases you won't and you can get a sloppy or even bad results
because
of rendering engine paths. For example, because style is not applied
until
later you have an issue here
h2 class=nostyleimg src=error.gifWarning: Styles required for
correct rendering/h2
The network request happens regardless of situation no assuming images
on.
That doesn't seem like a very serious issue. Just don't use images if
you care that much. A large percentage of non-CSS browsers are
probably text-based anyway.
It isn't but hints at what the motivation was from a real world request (see
below)
For example, using the content property can be somewhat troubling if
style is removed. For example, consider what happens if you are putting
in
field required indicators
input[type=text].required:before {content: (*) }
This should just use HTML5's required attribute instead of a class:
http://dev.w3.org/html5/spec/Overview.html#the-required-attribute
Agreed that is the case, this is more documenting the usage of designers
not that there isn't an HTML 5 appropriate solution.
Conformant browsers should make it clear to the user that the field is
required even if styles are disabled.
yes they should.
or for offsite links
a[href^=http://]:after {content:' ( Offsite Link )';}
This is non-essential info, and every browser I've heard of exposes it
anyway (e.g., by hovering over the link and looking in the lower
left).
or any other dynamic insert this way.
Do you have any other examples where this is a significant issue?
Those two don't seem like a big deal to me, honestly, even if it were
logistically possible to get nostyle supported widely enough to be
useful.
Those were just examples of more valid uses of content actually. Of course
as I mentioned below people can abuse this property and then it does become
a big deal. But dynamically having content jam in all sorts of stuff
client-side seems wrong-headed so I certainly don't suggest codifying bad
practices though mitigating them somehow seems appropriate.
If CSS is necessary for a site to operate, it's probably being
misused. If an author is misusing CSS this badly, it's not clear to
me why they could be expected to reliably use nostyle. The contents
of nostyle also don't make a difference to almost anyone, so authors
who use it won't really understand the purpose it serves and it will
probably be misused more often than used.
You may be quite right. Understand my purpose of proposing this was mostly
due to some contrivances to determine style and no-style support for an
effort which is very contingency concerned. The solution that was adopted
using scripting, server-side logging particularly triggered by image
requests from background-image values or their absence, etc. can figure all
cases but it was a mess and thus the why not have a nostyle wouldn't life
be easier So from where you sit yes it is not that important likely, from
having to wrestle with it I would have loved to have an easy solution.
Anyway I will say that there is a
bit of symmetry of having on/off cases for all the various client-side
technologies
(img, script, object,
etc.), but I see that the off aspect of style could simply be thought
of as the markup itself and that is
certainly fine it has worked for most so far.
Re: [whatwg] nostyle consideration
On Mon, Jun 15, 2009 at 4:23 PM, Kornel Lesinski kor...@geekhood.netwrote: On Mon, 15 Jun 2009 21:26:21 +0100, Thomas Powell tpow...@gmail.com wrote: 1) Head Usage nostyle meta http-equiv=Refresh content=0;url=/errors/stylerequired.html /nostyle 2) Body Usage nostyle h2Warning: Styles required for correct rendering/h2 /nostyle Purpose of this element seems to make lack of CSS not my problem instead of providing meaningful alternative. This is not helpful for users without CSS. It only helps authors to discriminate against them, and I'm strongly against it. There is no intention of that in the proposal, you seem to have eliminated the discussion about dynamic content which is also discrimentory of such users as well as well as the error reporting examples. I showed a variety of negative and positive cases. My interest here in this tag in fact has grown out of a problem with lack of understanding of users with various capabilities rather than some particular design or tech agenda. Comments? noscript is a very poor solution, and nostyle would be too. You should use graceful degradation/progressive enhancement instead (in both cases). Couldn't agree more about the architecture, if you read any of my books particularly my Ajax one I am strong proponent of falling back not locking out, but obviously that choice is philosophical not technical. A negative lock out approach can be accomplished whether or not this element exists though as you say it makes it easier for some to treat a class of users bad. While I am not sure that markup elements can really force a philosophy of Web design/dev though they can certainly encourage it and so I understand the passion of not wanting to enable tech abusers any more than we have to, so point taken, but it actually doesn't fit with my experience. Consider your opinion of the value of noscript for me I have to disagree it has been quite valuable. In fact my main use is simply to show people about the reality of people turning things off or not supporting script rather than letting them cite arbitrary hear say about the issue. We have customers that have used it just to quantify exactly what you are worried about - down level user-agents or script off folks. It has really helped me get people on board with seeing the realities of addressing such contingency cases. Log files could certainly do this too but in the age of script based Google analytics unlikely for most. Given the blissful ignorance about measuring script use it would be great to see a noscript tag (or maybe even this dreaded nostyle) being employed for good because in many cases the discrimentory use of Web tech changes once people see the traffic they fail to serve properly to in a measurable manner rather than an abstract statement about what they ought to do (at least rational corporate types act that way if experience is a judge). Anyway I am sure you can think of a bunch of bad uses of JS, but that if anything only proves the point of the need, if a site owner is going to be restrictive for better or worse it would be better to be aware of your choice in a quantifiable way and error to your users properly? In short I simply view this nostyle element simply as a symmetrical element to other aspects of Web tech: on state/off state that's it. It can be used for good or ill like most anything and it actually supports a view of awareness of all rendering cases by its mere availability. Judging by comments it would appear that some view the style off state of being handled just fine with plain markup. -Thomas -- regards, Kornel Lesinski
