Kenji Baheux | 28 Nov 06:30 2014

Re: [css-fonts] font prefetch hints

I just caught up on the discussion and agree that the original <at> will-use idea has inherent issues that makes it a poor fit for the use case.


>> - Perhaps we can extend url() to accept extra parameters? e.g.
>> url("http://...",
>> <fetch init options>?)

Does it mean that we would end up with redundant information when an <at> font-face specifies multiple formats?


<at> font-face {
  font-family: myFont;
  src: url('myFont.eot?', <fetch init options>) format('eot'),
 url('myFont.woff' , <fetch init options>) format('woff'),
 url('myFont.ttf', <fetch init options>) format('truetype');
}


I imagine we would also want to give the same hints for the local() case:

src: local('Open Sans', <fetch init options>), [...]


In light of these redundancies, the generic "fetch-settings" attribute approach is appealing:

<at> font-face {
    font-family: myFont;
    src: local('myFont'),
           url('myFont.eot?') format('eot'),
   url('myFont.woff') format('woff'),
   url('myFont.ttf') format('truetype');
    fetch-settings: preload <fetch init options>?;
}


However, the url parameter seems a much better fit for other use cases:

body {
    background-image: url("bg.png", <fetch init options>);
}

vs.

body {
    background-image: url("bg.png");
    fetch-settings: preload <fetch init options>?;
}
Philip Walton | 27 Nov 19:08 2014

[css-scoping] should `::content` match both <content> and <shadow> insertion points?

I've been experimenting with various "inheritance" techniques using web components, and I encountered what I consider to be unexpected behavior in Chrome. Here's a jsbin example:

To summarize, I'm creating two shadow roots on an element. The younger shadow root contains a <shadow> insertion point and the older shadow root contains a <content> insertion point.

In the younger shadow DOM I have a <style> defined as follows:

:host::shadow ::content > * {
  border: 1px solid;
  margin: .5em;
  padding: .5em;
}

Since there is only one <content> insertion point, and since the element in the main DOM only has one set of children, I'd expect this selector to only match the element's children in the main DOM, but as you can see from the example, it's also matching the <nav> element in the older shadow root (if you look at the example, I would have expected that only the links would have borders).

If this behavior is considered correct, I'd argue it's confusing and maybe `::content` should have a different name, since insertion points can also be created with a <shadow> tag. If  this behavior is incorrect, well, I guess I'll report a bug.
Simon Sapin | 27 Nov 18:30 2014

[css2] Fixed table layout: width distribution between non-auto columns

In http://dev.w3.org/csswg/css2/tables.html#fixed-table-layout
> The width of the table is then the greater of the value of the
> 'width' property for the table element and the sum of the column
> widths (plus cell spacing or borders). If the table is wider than the
> columns, the extra space should be distributed over the columns.

This does not say *how* the space is distributed. I assumed it was 
equally, but Firefox, Chromium, Safari and IE seem to have interop to 
make it proportional to the widths of the columns “so far”.

Test case:

<table style="table-layout: fixed; width: 400px; border-spacing: 0">
   <td width="50" style="background: #ff0000; height: 100px">
   <td width="150" style="background: #00ff00; height: 100px">
</table>

https://rawgit.com/servo/servo/59cdce30010/tests/ref/table_specified_width_a.html

The sum of the column widths at the beginning of the quoted part of the 
algorithm is 200px, and the width of the table is 400px. If the extra 
space (200px) was distributed equally, the columns would gain 100px each 
and end up at 150px and 250px. Instead, in every browser, they gain 50px 
and 150px respectively and end up at 100px and 300px.

Context:

https://github.com/servo/servo/pull/4114
https://github.com/servo/servo/issues/4121

I did not find a test case in 
http://test.csswg.org/suites/css21_dev/nightly-unstable/html4/chapter-17.htm#s17.5.2.1 
that seemed relevant.

--

-- 
Simon Sapin

Edu Pascual | 27 Nov 17:05 2014
Picon

Re: [whatwg] <di>? Please?

Shouldn't this do the job?

dd {
    display:none;
}
dt:focus ~dd {
    display:block
}
dt:focus ~ dt ~ dd {
    /* Hides again any dd that follows a dt that follows the focused dt */
    display: none;
}

The feature you are suggesting sounds interesting, but your use case seems to be solved by already existing features.

Regards,
Edu Pascual

On 22 November 2014 at 00:16, Young, Brennan <Brennan.Young <at> laerdal.dk> wrote:
Just run into a problem which I expected to be relatively common, but apart from this thread, I have found little discussion about it, or any indication that the proposed CSS level 4 selectors will present a solution.

Ian Hickson wrote "(Though really, how often do you have a collapsible dt/dd group that has  more than one dt or dd?)"

.... not often, but it's a valid case. I am sitting with exactly such a case right now.

For example, I have a quite large definition list with hundreds of entries. In this case, dt appears only once for each entry, but there are multiple (and variable numbers of) dds.  Something like this:

<dl>
    <dt>Foo</dt>
    <dd>Egg Foo Yung</dd>
    <dd>Football</dd>
    <dd>Foolishness</dd>

    <dt>Bar</dt>
    <dd>Barry Manilow</dd>
    <dd>Barchester Chronicles</dd>

</dl>

I want the dds to be hidden. I'd like to be able to click on (or tab through to) a dt, giving it focus, and then its corresponding dds should become visible.

I hoped to do

dd {
    display:none;
}
dt:focus ~dd {
    display:block
}

.... but this will show *all* subsequent dds after the focused dt.

It's been suggested that I give a class to each 'group' of dts and dds, which works today, but this will bloat my css file in proportion to the length of the list. I mentioned that the list is very long? There are also multiple documents with comparably long lists, and I want them to share the same css file. So, the class/id solution is not great.

dt:focus + dd and variants with additional + selectors are not good because I don't know how many dds there will be.

One solution proposed here is to add markup, either by permitting div or li inside dl, or by introducing the mooted di (the subject line of this thread).

But this seems messy, considering that the browser already knows how to associate dts with dds. So I agree with the view that this should be solved in css, not in markup.

(I will use a javaScript workaround today, of course, but this is a presentation issue, and therefore CSS should be able solve it).

What I am looking for is a selector, somehow similar to the sibling selectors ~ or +, but which 'stops' selecting siblings when an element of a different type appears.
In this case it might select all subsequent dds until something that is not a dd appears.

jQuery's nextUntil() offers something similar. That feature would not have been added if there were no use case for it.

I suppose it might otherwise be imagined as a kind of 'contiguous' selector'. Select one element, and all contiguous sibling elements of the same type will get selected.

Could also be used to select all paragraphs following a heading, up until the next non-paragraph etc.

Obviously not a formal proposal, but does this appear reasonable? Are there any other fantasies?







Nicolas Duclos | 18 Nov 23:53 2014
Picon

Datalist suggestion


Hi,

I'm creating a contact form and I was using the <select> tag and I
discovered the <datalist> tag and I think it's very useful, because it's
dynamic (you can write and have some options at the same time). The
problem is that I can't minimize the list of option with size="5" like
with <select> tag. With <datalist>, I have like 30 options showing at
the same time without scrollbar, so we can't see all of them...

My suggestion is to add css style like <select> to change how the
datalist look (color, shape, etc) and to be able to only show the first
X options in the list when you are clicking to write what you want.
 
thank you

Dan Elebash | 11 Nov 01:01 2014
Picon

[css-grid] feedback

·        It’s a minor thing but I think 1.3Source Independence in the TOC of the working draft and editor drafts should be renamed to Source Order Independence, it just is more clear that it’s the order of the source that is independent, not the actual source itself.

Thanks,

Dan

 

Bryce Otis | 26 Nov 21:41 2014
Picon

http://www.idpf.org/epub/altss-tags/) +Thought

My goal is to write one ePUB that behaves the same regardless of UA


This is how I currently understand Stylesheet mechanics:


The W3C method: (ePaper devices & non-Color printers may have their own Grayscale conversion, but this allows Filters to be matched to Themes)

<head><!--Media Queries can occur outside Stylesheets (Device Validation)-->

<title>W3C Matrix</title><!--PERSISTANT: Output Layer (Formating & Layout) PREFERED: Theme Layers (Color Selection)-->

<link class="speech" href="url/Speaker.css" rel="pronunciation" type="text/css" /><!--Alternate Stylesheet for Media-Type: Speech-->

<link class="print" href="url/Printer.css" media="print and (color), print and (monochrome)" rel="alternate stylesheet" type="text/css" />

<link class="horizontal" href="url/Horizontal.css" media="all and (orientation: landscape)" rel="alternate stylesheet" type="text/css" />

<link class="vertical" href="url/Vertical.css" media="all and (orientation: portrait)" rel="alternate stylesheet" type="text/css" />

<link class="screen" href="url/PERSISTANT.css" media="screen and (color), screen and (monochrome)" rel="stylesheet" type="text/css" />

<link class="sepia" href="url/Color-Sepia.css" media="screen and (color)" rel="stylesheet" title="Color: Sepia" type="text/css" />

<link class="day" href="url/PREFERED.css" media="all and (color)" rel="stylesheet" title="Color: Day" type="text/css" />

<link class="night" href="url/Color-Night.css" media="all and (color)" rel="stylesheet" title="Color: Night" type="text/css" />

<link class="day" href="url/Gray-Day.css" media="all and (monochrome)" rel="stylesheet" title="Gray: Day" type="text/css" />

<link class="night" href="url/Gray-Night.css" media="all and (monochrome)" rel="stylesheet" title="Gray: Night" type="text/css" />

</head><!--PERSISTANT: [Browser] ALTERNATE: [Speaker] or [Orientation (Print/Screen)] PREFERED: [Color (Sepia)] or [Color/Gray (Day/Night)]-->

Observation: Trident shows all five PREFERED choices, while Gecko seems to validate screen="color" so it only shows three.


The WebKit method:

<head><!--Media Queries only occur inside Stylesheets (WebKit Validation)-->

<title>WebKit Matrix</title><!--Default: Android & iOS Devices-->

<link href="url/PERSISTANT.css" rel="stylesheet" type="text/css" /><!-- <at> media imports Speech/Print/Orientation-->

<link href="url/PREFERED.css" rel="stylesheet" title="Themes" type="text/css" /><!--? <at> webkit and/or <at> import ?-->

</head><!--No ALTERNATE Stylesheets-->

The vast majority of mobile eReading devices are: Android  (B&N Nook, Kindle Fire, etc.), or iOS (iPad, iPhone, iPod Touch)


The part I am fuzzy on, is how to match Themes with WebKit's Validation model, if I'm even using the correct terminology...


An analogy would be how Filters load from CSS:

img.desaturate { /* Grayscale Filter */ 

  -webkit-filter: grayscale(100%); /* WebKit */

  -moz-filter: grayscale(100%); /* Gecko */

  filter: grayscale(100%); /* W3C */

  filter: gray; /* v6-9 Trident (v10-11 ≡ JavaScript) */

}


Where: (iBooks) Validator [adaptivegarage's example]

:root[__ibooks_internal_theme*="|White|Sepia|Night|"] /* elements */ {

   /* ... override your CSS here ... */

}


  • What would be the validator for Google (Play Books)?
  • What would be the validator for generic (WebKit)?
  • We know the validator for Gecko & Trident = (W3C)
Young, Brennan | 22 Nov 00:16 2014
Picon

Re: [whatwg] <di>? Please?

Just run into a problem which I expected to be relatively common, but apart from this thread, I have found
little discussion about it, or any indication that the proposed CSS level 4 selectors will present a solution.

Ian Hickson wrote "(Though really, how often do you have a collapsible dt/dd group that has  more than one dt
or dd?)"

.... not often, but it's a valid case. I am sitting with exactly such a case right now.

For example, I have a quite large definition list with hundreds of entries. In this case, dt appears only
once for each entry, but there are multiple (and variable numbers of) dds.  Something like this:

<dl>
    <dt>Foo</dt>
    <dd>Egg Foo Yung</dd>
    <dd>Football</dd>
    <dd>Foolishness</dd>

    <dt>Bar</dt>
    <dd>Barry Manilow</dd>
    <dd>Barchester Chronicles</dd>

</dl>

I want the dds to be hidden. I'd like to be able to click on (or tab through to) a dt, giving it focus, and then its
corresponding dds should become visible.

I hoped to do

dd {
    display:none;
}
dt:focus ~dd {
    display:block
}

.... but this will show *all* subsequent dds after the focused dt.

It's been suggested that I give a class to each 'group' of dts and dds, which works today, but this will bloat
my css file in proportion to the length of the list. I mentioned that the list is very long? There are also
multiple documents with comparably long lists, and I want them to share the same css file. So, the class/id
solution is not great. 

dt:focus + dd and variants with additional + selectors are not good because I don't know how many dds there
will be.

One solution proposed here is to add markup, either by permitting div or li inside dl, or by introducing the
mooted di (the subject line of this thread). 

But this seems messy, considering that the browser already knows how to associate dts with dds. So I agree
with the view that this should be solved in css, not in markup. 

(I will use a javaScript workaround today, of course, but this is a presentation issue, and therefore CSS
should be able solve it).

What I am looking for is a selector, somehow similar to the sibling selectors ~ or +, but which 'stops'
selecting siblings when an element of a different type appears. 
In this case it might select all subsequent dds until something that is not a dd appears.

jQuery's nextUntil() offers something similar. That feature would not have been added if there were no use
case for it.

I suppose it might otherwise be imagined as a kind of 'contiguous' selector'. Select one element, and all
contiguous sibling elements of the same type will get selected.

Could also be used to select all paragraphs following a heading, up until the next non-paragraph etc.

Obviously not a formal proposal, but does this appear reasonable? Are there any other fantasies?

Yannick Lohse | 5 Nov 22:29 2014
Picon

Re: [css-flexbox] Renaming flex-basis:auto for less confusion

I'm also for number 2. Having used flexbox for a while now I'm fairly 
used to the idea that auto means size look-up when dealing with flexbox. 
`content` may not be too intuitive but there are already a number of 
not-too-intuitive keywords in the flexbox spec, so I'd rather have 
another one than break backwards compat.

Michiel Bijl | 5 Nov 11:01 2014
Picon

UNS: [Moderator Action] [css-pseudo] allowed values for CSS alt

Bruce Lawson brought the new alt attribute for generated content to my 
attention on Twitter[1]. With all these icon fonts that float around the 
web, I think it is a good thing you can specify an alt text. This does 
bring up some concerns, though. As Bruce stated on Twitter[2]:

> Content in CSS *is* yuck. But the foo:before {content: "blah"} ship 
> has sailed.

I do agree that content in CSS is yuck, but can definitely see the 
advantages of generated content. 'content:' within ::before and ::after 
takes a couple of values, one of which is 'attr(<identifier>)' [3]. This 
way you can use the content of an attribute on the element the rule 
applies to. I suggest we add the same value to the 'alt' attribute [4]. 
This could help with translations, but also uphold one of the core 
principles of the web:

> Separation of Concerns
>
> HTML should allow separation of content and presentation. [5]

—Michiel Bijl

[1]: https://twitter.com/brucel/status/529920245126164480
[2]: https://twitter.com/brucel/status/529926547189534720
[3]: 
http://www.w3.org/TR/2009/CR-CSS2-20090908/generate.html#propdef-content
[4]: http://dev.w3.org/csswg/css-pseudo/#alt-property
[5]: 
http://www.w3.org/TR/html-design-principles/#separation-of-concerns

Moonchild | 31 Oct 01:11 2014

[css-flexbox] min-height/min-width auto in spec or not?


Hello!

I'm currently working on flexbox layout implementations in my browser (Pale
Moon), and there seems to be a good amount of contradictory information
about the use of min-width:auto and min-height:auto in flexboxes.

According to some past communication from Mozilla, this keyword was being
removed from the spec. But the current "last call" Working Draft for this
spec has it included, and it is also in the test suites. (Par 4.5)

Can you please provide clarity if this is likely going to be included in the
final spec for flexboxes or not, so I know if i should implement this or not?

Thanks in advance,

  Mark.

Gmane