Re: [cssom] Drop support for alternative stylesheets?

On Thu, 29 Aug 2013 22:41:50 +0200, Gérard Talbot <www-style@gtalbot.org>  
wrote:

> Le Jeu 29 août 2013 10:17, Simon Pieters a écrit :
>> In the context of this bug
>>     https://www.w3.org/Bugs/Public/show_bug.cgi?id=22479
>> it was suggested that it may be time to drop support for alternative
>> stylesheets in the Web platform.
>
> CSS Object Model (CSSOM)
> Editor's Draft 28 August 2013
> 6.2.3 Extensions to the Document Interface
> http://dev.w3.org/csswg/cssom/#extensions-to-the-document-interface
>
>> In data set 18/06/2013 http://webdevdata.org I see 368 sites out of
>> 53,000
>> using alternate stylesheets (with <link>), so that's 0.7%.
>> For the API, I see 0 instances of selectedStyleSheetSet,
>> selectedStylesheetSet or enableStyleSheetsForSet.
>
> Simon,
>
> Are there any browser which currently and correctly support
> a) selectedStyleSheetSet attribute?
> b) selectedStylesheetSet attribute?
> c) lastStyleSheetSet attribute?
> d) preferredStyleSheetSet attribute?
> e) styleSheetSets attribute?
> f) enableStyleSheetsForSet()?
>
> I ask because I do not know these answers.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2500

Presto: none
WebKit and Blink: only the non-standard selectedStylesheetSet, but setting  
it does nothing.
Gecko: all except the non-standard selectedStylesheetSet
IE10: none


>> There might be pages
>> that use <link>.disabled to switch, but this seems a bit harder to look
>> for. Also the data doesn't include external scripts.
>> 3 sites use <meta http-equiv=Default-Style>, but they don't have
>> differently-titled stylesheets. 0 sites use Default-Style HTTP header.
>> There could be sites that only include the header if the user has chosen
>> a
>> different style sheet set (and the site stores the choice in a cookie),
>> but this seems hard to check for.
>> WebKit and Blink don't load alternative stylesheets

It seems I was wrong on this part. Looking at the network tab in Chrome's  
inspector I see loads for alternative stylesheets on page load.


>> and don't put them
>> in
>> document.styleSheets. Toggling .disabled doesn't work. The CSSOM API for
>> switching stylesheets isn't implemented.
>
> Simon,
>
> In the final analysis, why should alternate stylesheets be dropped?

Basically because the feature has had its chance to prove itself and it  
has failed.


> Because it isn't popular?

Yes.


> Because it isn't implemented in browsers?

Yes.


> Because it wouldn't be useful, helpful?

It could be useful for some users, but it seems to me like the user demand  
hasn't been strong enough.


> Because developing alternate
> stylesheets involves/requires time, efforts, energy?

No, that's fine.


> Because the UI is not
> optimal?

I'm not a UI expert, but I think it makes more sense to let the page  
provide the UI than the browser.


> Personally, I would not be able to establish the (advantages versus
> inconvenient balance sheet) trade-offs regarding the decision to drop
> support for alternative stylesheets in the Web platform.
>
>
>> The only thing that does seem to
>> work is changing Default-Style, but doing so leaves the CSSOM in a weird
>> state: the old stylesheet is emptied of its cssRules and the new
>> stylesheet still isn't exposed.
>> Firefox and IE10 have UI for switching stylesheets.
>
> I think it must be said that IE8 had bugs and limitations to alternate
> stylesheets and, as such, this didn't help its adoption.

Indeed.


>> Only Firefox support
>> the CSSOM APIs for switching stylesheet sets. (Don't know about IE11.)
>> It would be interesting to have data on how often users switch
>> stylesheets, both using the browser's UI and using JS-based switchers
>> provided by the page (I think most such switchers just toggle .disabled
>> on
>> <link>).
>
> The only known way to switch alternate stylesheets - at least for Presto
> and Webkit - is to toggle disabled attribute of <link> via js.

This appears to be a bit buggy in WebKit and Blink. Alternative  
stylesheets have their .disabled as false initially, so setting .disabled  
= false does nothing. However, setting .disabled = true and then .disabled  
= false makes it enabled.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2501 (pressing  
'enable b' makes both styles disabled, but pressing 'enable a' and then  
'enable b' enables the b stylesheet)


>> The API around alternative stylesheets assume that non-preferred
>> stylesheets are loaded (and present in document.styleSheets). Doing so
>> is
>> bad for performance for users that don't switch stylesheets on pages
>> that
>> have alternative stylesheets (or arguably it's bad for all users).
>
> I agree: it's bad for performance.
>
> It is also true that *_many_* sites use and declare 12+ linked
> stylesheets, sometimes with hundreds of declarations each, totaling
> thousands of declarations, with many resetting and re-resetting ones,  
> with
> complex rules, over-qualified selectors, with over-excessive amount of
> containers, etc.. Most of the time, these sites declare all of the
> stylesheets which would be needed to view any or all of the webpages of
> the site... but if you visit only 1 page, then your browser loads all of
> the stylesheets, rules, declarations in memory anyway when the page could
> be requiring only 10% of all that is declared and loaded. Same thing with
> minified advanced javascript librairies (jQuery, mootools, etc).

That seems like a reason for browsers to not load things that aren't going  
to be used.


>> If a user wants to switch styles on a site, presumably the user wants
>> the
>> switch to persist across page navigations. This is not the case with
>> alternative stylesheets without cooperation of the site -- it needs to
>> manually store the choice and manage which style sheet to have enabled
>> on
>> page loads.
>
> Selection persistence across page navigation is indeed a very important
> issue. Mark "Tarquin" Wilton-Jones website
> http://www.howtocreate.co.uk/
> uses alternate stylesheets, stores the user's selection in a cookie.

Yeah. At the same time there are pages that don't store the selection,  
maybe on the assumption that it's the browser's responsibility to do that.  
If we remove the feature, it makes it clearer that it is the Web  
developer's responsibility to store the selection. (Having the browser  
store the selection is non-trivial since it can't know how to scope a  
"site" -- different pages from the same origin might have different sets  
of stylesheets, or multiple origins might want to share stylesheet  
selection).


>> My proposal right now is, for the sake of discussion, to drop everything
>> that has to do with alternative stylesheets (which most closely matches
>> what WebKit and Blink do today). Are Mozilla and Microsoft OK with that?
>> --
>> Simon Pieters
>> Opera Software
>
> With Google Chrome 29.0.1547.62, I use Style Chooser 1.2
> https://chrome.google.com/webstore/detail/style-chooser/daodklicmmjhcacgkjpianadkdkbkbce
> which allows me to select an alternate stylesheet in a page via a menu.
>
> Eg. The KazGarden-Project uses 30 alternate stylesheets
> http://www.gimp-werkstatt.de/kaze/
>
> Gérard


-- 
Simon Pieters
Opera Software

Received on Thursday, 29 August 2013 22:05:27 UTC