Issues with @media tests

8 views
Skip to first unread message

Garth Conboy

unread,
Apr 17, 2014, 8:59:11 PM4/17/14
to epub-testsu...@googlegroups.com
Hi Folks,

I think some of the @media tests are in need of tuning.

The definition of “handheld” is so wishy washy (“typically small screen and low bandwidth”) that I think this test should just be removed. At the very least the instructions for grading the test should become “If the preceding paragraph reads FAIL when displayed on a device considered a handheld, this test fails.”

For TV, the definition of the device may be clearer, but the criteria for passing is wrong — the instructions for grading the test should be “If the preceding paragraph reads FAIL when displayed on a TV device, this test fails.”

Similarly the instructions for grading the portrait and landscape tests need to be fixed to be orientation-specific:

“If the preceding paragraph reads FAIL when displayed in portrait orientation, this test fails.” and:

“If the preceding paragraph reads FAIL when displayed in landscape orientation, this test fails.”

Best,
Garth

Ric Wright

unread,
Apr 18, 2014, 7:32:52 AM4/18/14
to epub-testsu...@googlegroups.com
Running through the @media styling tests this morning (EPUB 101, tests 210-213).  I am kind of wondering what the tests are telling us.  Take the “handheld” test (212).  The HTML content is:

   <section id="style-212" class="ctest">

    <h3><span class="nature">[REQUIRED]</span> <span class="test-id">style-212</span> <code>handheld</code></h3>

    <p class="desc">Tests whether the <code>@media</code> rule set to <code>handheld</code> is supported.</p>

    <p class="media-handheld">FAIL</p>

    <p class="eval">If the preceding paragraph reads "FAIL", the test fails.</p>

    </section>


And the CSS:


@media handheld

  {p.media-handheld {display:none;}}


So if the underlying rendering system responds to the @media handheld with “no this is not a handheld device” the rule isn’t applied and the the test “Fails”.  But does it really?  I am testing with a iPad which Webkit categorizes as NOT a handheld.  So isn’t the fact that the rule is NOT applied the correct behaviour?  I believe the answer is yes.


Seems like the test SHOULD be something like


“If the preceding sentence says that your device is NOT a handheld device and it is not a handheld device, then the test passes.”


And the HTML would be:


    <p class="media-handheld>This device is NOT a handheld device</p>


Alternatively one could invert the logic (probably better).  But the point is that as far as I can tell, Webkit says that the iPad IS “all” and IS a “screen” but is NOT a “handheld” and NOT a “tv”.  All of which are correct.


Ric


--
You received this message because you are subscribed to the Google Groups "epub-testsuite-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to epub-testsuite-di...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ori Idan

unread,
Apr 18, 2014, 1:22:37 PM4/18/14
to epub-testsu...@googlegroups.com
I disagree with your definition of handheld.
Handheld device is simply a device you usually hold in your had rather then put on a table. All tablets are considered hand held whether their screen is 7" or 10"

-- 
Ori Idan CEO Helicon Books





On Fri, Apr 18, 2014 at 3:59 AM, Garth Conboy <ga...@google.com> wrote:
Hi Folks,

I think some of the @media tests are in need of tuning.

The definition of "handheld" is so wishy washy ("typically small screen and low bandwidth") that I think this test should just be removed.  At the very least the instructions for grading the test should become "If the preceding paragraph reads FAIL when displayed on a device considered a handheld, this test fails."

For TV, the definition of the device may be clearer, but the criteria for passing is wrong -- the instructions for grading the test should be "If the preceding paragraph reads FAIL when displayed on a TV device, this test fails."


Similarly the instructions for grading the portrait and landscape tests need to be fixed to be orientation-specific:

"If the preceding paragraph reads FAIL when displayed in portrait orientation, this test fails." and:

"If the preceding paragraph reads FAIL when displayed in landscape orientation, this test fails."

Best,
   Garth

Garth Conboy

unread,
Apr 18, 2014, 2:01:07 PM4/18/14
to epub-testsu...@googlegroups.com
Hi Ori,

My quote yesterday:

handheld
Intended for handheld devices (typically small screen, limited bandwidth).


And to my experience many tablets do not consider themselves “handheld”.  E.g. the modern WebViews on Android tablets don’t consider themselves handhelds.

Best,
   Garth

Matt Garrish

unread,
Feb 12, 2015, 6:37:35 PM2/12/15
to epub-testsu...@googlegroups.com
I'm going to drop handheld, as suggested, but I'm also wondering about the other tests. Why is it required that screen or tv be supported, or orientations. I'm thinking these should all be optional tests, as I agree they should all be conditional "if x and y then z".

And if we're going to test widths, shouldn't we use values that can't fail, like "1" for min and "99999" for max? 200px is probably safe on the bottom end, but if we're testing max widths 2000px doesn't seem quite so bulletproof.

I also disagree with the wording for the width tests. EPUB doesn't require support for specific values. The tests should say more simply that they test whether the given min/max width property is supported. (Hence the need for more bulletproof numbers.)

Any thoughts?

Matt

Garth Conboy

unread,
Feb 12, 2015, 8:45:51 PM2/12/15
to epub-testsu...@googlegroups.com
I agree with you Matt!   (as you might have expected, since I started this thread in 2014 [on my birthday, evidently]).

Best,
   Garth

Matt Garrish

unread,
Feb 12, 2015, 10:28:49 PM2/12/15
to epub-testsu...@googlegroups.com
Ya, this section is giving me fits now that I look at it closer. We’re blurring the lines of reading system and device the way we’re currently testing many of the rules.
 
I’m wondering if we should only test “@media all” and reword the test to whether selection by media type name is supported? We’re moving out of support for functionality and into how devices identify themselves by checking individual names.
 
I guess for orientation we can also be explicit that the device must allow reorientation of the content, otherwise skip the test. But it appears that at least some testers were doing that.
 
And why do we only test width and not height or aspect ratio, now that I’m on a roll? A case of if we test one we can assume the others?
 
(What kind of horrible birthday were you having that you dug into these?!? :)
 
Matt

Daniel Weck

unread,
Feb 13, 2015, 7:15:18 AM2/13/15
to epub-testsu...@googlegroups.com
I recently implemented support for EPUB3 Multiple Renditions in
Readium (prototype / pilot project, not ready for public use just
yet). This involves handling CSS Media Queries outside of the context
of a cascaded stylesheet, i.e. by manually hooking into the MQ API to
register event listeners (for example, switch to a different OPF
rendition when the viewport aspect ratio is altered, or when the
device orientation changes).

http://www.idpf.org/epub/renditions/multiple/#h.v5umqueir7kw

From an technical standpoint, I would expect Reading System
implementers to leverage the existing browser / WebView support for
Media Queries, not to reinvent the wheel (e.g. no custom parser for MQ
rules, etc.).
Consequently, from a QA perspective, I would expect the tests to
verify one common rule (such as device width), but not to attempt to
check an exhaustive list of possible criteria. The test would fail
with a message like "test fail: this reading system does not appear to
support CSS Media Queries", or to succeed with "test pass: this
reading system appears to support CSS Media Queries (only the 'device
width' rule was checked)"...something along those lines.

Sorry if I am slightly off the mark in this discussion, I have not
looked at the test in detail. I just wanted to bring implementation
feedback :)

Daniel

Matt Garrish

unread,
Feb 13, 2015, 7:39:08 AM2/13/15
to epub-testsu...@googlegroups.com
Thanks, Daniel!

That's basically what I've been wondering, but I wasn't sure if the intent
was to differentiate between 2.1 support and level 3 support, and if it was
the case that if you support level 3 that maybe only some aspects of it are
supported.

Would it make sense to reduce to two tests, "@media all" to test for 2.1
support and one of the width/orientation tests to check for level 3 support?

Matt

Garth Conboy

unread,
Feb 13, 2015, 12:04:58 PM2/13/15
to epub-testsu...@googlegroups.com
Sounds good to me.

Could also keep orientation, perhaps with the likes of;

“If the preceding paragraph reads FAIL when displayed in portrait orientation on an RS that supports two orientations, this test fails, otherwise it passes.” and:

“If the preceding paragraph reads FAIL when displayed in landscape orientation  on an RS that supports two orientations, this test fails, otherwise it passes.”

As that's kinda an important one.

Best,
   Garth


On Fri, Feb 13, 2015 at 4:39 AM, Matt Garrish <matt.g...@bell.net> wrote:
Thanks, Daniel!

That's basically what I've been wondering, but I wasn't sure if the intent was to differentiate between 2.1 support and level 3 support, and if it was the case that if you support level 3 that maybe only some aspects of it are supported.

Would it make sense to reduce to two tests, "@media all" to test for 2.1 support and one of the width/orientation tests to check for level 3 support?

Matt

-----Original Message----- From: Daniel Weck
Sent: Friday, February 13, 2015 7:15 AM

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"epub-testsuite-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"epub-testsuite-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "epub-testsuite-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to epub-testsuite-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "epub-testsuite-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to epub-testsuite-discuss+unsub...@googlegroups.com.

Matt Garrish

unread,
Feb 13, 2015, 12:46:16 PM2/13/15
to epub-testsu...@googlegroups.com
Sure, sounds good. I’ve updated the tests now. Diff is at [1] and source at [2] if people want to verify whether what we have now is better or not.
 
To unsubscribe from this group and stop receiving emails from it, send an email to epub-testsuite-di...@googlegroups.com.

Garth Conboy

unread,
Feb 13, 2015, 6:04:05 PM2/13/15
to epub-testsu...@googlegroups.com
Medium quick look.... LGTM (Looks Good To Me).

Best,
   Garth

Ric Wright

unread,
Feb 19, 2015, 1:27:53 PM2/19/15
to epub-testsu...@googlegroups.com
Sorry to be late to the party on this, but I am kind of swamped (qualifying our latest builds, running the project and preparing to move our house).  I raised this issue before (last April) and still feel the same way:

Running through the @media styling tests this morning (EPUB 101, tests 210-213).  I am kind of wondering what the tests are telling us.  Take the “handheld” test (212).  The HTML content is:

   <section id="style-212" class="ctest">

     <h3><span class="nature">[REQUIRED]</span> <span class="test-id">style-212</span> <code>handheld</code></h3>

     <p class="desc">Tests whether the <code>@media</code> rule set to <code>handheld</code> is supported.</p>

     <p class="media-handheld">FAIL</p>

     <p class="eval">If the preceding paragraph reads "FAIL", the test fails.</p>

     </section>


And the CSS:


@media handheld

  {p.media-handheld {display:none;}}


So if the underlying rendering system responds to the @media handheld with “no this is not a handheld device” the rule isn’t applied and the the test “Fails”.  But does it really?  I am testing with a iPad which Webkit categorizes as NOT a handheld.  So isn’t the fact that the rule is NOT applied the correct behaviour?  I believe the answer is yes.


Seems like the test SHOULD be something like


“If the preceding sentence says that your device is NOT a handheld device and it is not a handheld device, then the test passes.”


And the HTML would be:


    <p class="media-handheld>This device is NOT a handheld device</p>


Alternatively one could invert the logic (probably better).  But the point is that as far as I can tell, Webkit says that the iPad IS “all” and IS a “screen” but is NOT a “handheld” and NOT a “tv”.  All of which are correct.


Ric

Matt Garrish

unread,
Feb 19, 2015, 1:42:45 PM2/19/15
to epub-testsu...@googlegroups.com

Hi Ric,

 

Thhe handheld test is gone, as are the other specific media type name tests. The only remaining test is for support for “all”, and the test now states it only checks for support for css 2.1 media type names.

 

I also kept the min-width test (for at least 1px) and changed it to state that it checks support for media queries support.

 

This way we can differentiate if any reading systems support only the more basic media queries.

 

And finally, the orientation tests remain (optional), but are now worded to more clearly indicate that they only apply if the device supports two orientations.

 

Do these sound better to you?

 

Matt

 



Subject: Re: Issues with @media tests

Ric Wright

unread,
Feb 19, 2015, 1:58:45 PM2/19/15
to epub-testsu...@googlegroups.com
Sounds great!  Sorry to be slow catching up

Thanks
Ric

Matt Garrish

unread,
Feb 19, 2015, 2:03:42 PM2/19/15
to epub-testsu...@googlegroups.com

No worries. Now that I’ve got agreement from you and Garth, I’ll close off the issue in tracker.

Reply all
Reply to author
Forward
0 new messages