17 feb 2014 kl. 08:33 skrev MiB digital.disc...@gmail.com:
You could also use microformats and make it a part of a hcard (look
some text fell off there. It should be: You could also use microformats and
make it a part of a hcard (look up microformats and hcard
at and here too:
feb 16 2014 23:49 Andrew Cunningham lang.supp...@gmail.com:
The problem with b and i is that HTML5 gives them semantic meaning but
they also have inherent styling.
How is that different from any semantical element?
Of I use these elements in a multilingual envirnonment, then for some
feb 15 2014 06:22 Chris Williams ch...@clwill.com:
And how do they do that? How does the server know the user's page width?
By their going to m.example.com as opposed to example.com. Or with JS…
Javascript analysis of screen type will take care of a majority of users and
feed the relevant
is span any more semantic that b, i, em, or strong ?
On scanning it seems there were responses but none with respect to the
spec, which is usually very helpful: span (as well as div) have
literally no meaning—“[t]he span element doesn't mean anything on its
own” [1], “[t]he div element has no
On Feb 16, 2014, at 4:49 PM, Andrew Cunningham lang.supp...@gmail.com wrote:
The problem with b and i is that HTML5 gives them semantic meaning but
they also have inherent styling.
Of I use these elements in a multilingual envirnonment, then for some
languages I would need to change
I've always had a problem understanding why em and strong are supposedly
more semantic than i and b. Italics don't necessarily indicate emphasis and
bold doesn't necessarily indicate importance. Often they're nods to traditional
comprehension of things or to the organisation of a text so as to
Peter H. wrote:
I've always had a problem understanding why em and strong are
supposedly more semantic than i and b.
Because em means emphasised and strong means strongly emphasised
(semantic, saying nothing about how they will be rendered) whilst i
means set in italics and b means set in
El 17/02/2014, a las 11:01, Philip Taylor escribió:
Peter H. wrote:
I've always had a problem understanding why em and strong are
supposedly more semantic than i and b.
Because em means emphasised and strong means strongly emphasised
(semantic, saying nothing about how they will be
While bikeshedding around 'how semantic' people feel any given element to
be is a great laugh (although definitely off-topic for this list), I would
highly recommend the HTML specification for insight into the purpose of any
HTML element, especially when confusion arises over the possibility of
El 17/02/2014, a las 11:29, Barney Carroll escribió:
While bikeshedding around 'how semantic' people feel any given element to be
is a great laugh (although definitely off-topic for this list), I would
highly recommend the HTML specification for insight into the purpose of any
HTML
Barney Carroll wrote (probably citing one of the finite-but-unbounded
number of HTML 5 draft specifications) :
The em element isn't a generic italics element.
Correct. It has no connection with italics at all other than
a historical one.
Sometimes, text isintended to stand out from the
Which is precisely what I suggested as one of the two alternatives: use
JS to serve up content based on screen size.
On 2/17/14 12:27 AM, MiB digital.disc...@gmail.com wrote:
Javascript analysis of screen type ...
__
Only this group's mentor and creator can set the rules. Because this group
IS a forum for discussing CSS it seems right to limit fine-grained
how-to-do-it discussion to CSS only. But the use of CSS in the real world
invariably happens in a context that almost always includes a mixture of
17 feb 2014 kl. 17:48 skrev Chris Williams ch...@clwill.com:
Which is precisely what I suggested as one of the two alternatives: use
JS to serve up content based on screen size.
I underscored the importance from my perspective not having a separate ”mobile”
web site. Whatever the details,
feb 17 2014 18:05 Colin (Sandy) Pittendrigh sandy.pittendr...@gmail.com:
So
at higher big picture level some discussion about how CSS fits into the
overall scheme of things still seems appropriate.
Exactly.
Using Javascript cookies and (initially) a double GET to determine the
state of
MiB digital.disc...@gmail.com:
the choices a developer will have to make is about a complete system rather
than individual solution.
Solutions obviously. Sorry about that.
/MiB
__
css-discuss [css-d@lists.css-discuss.org]
It must be remembered that the presentation layer is optional, and CSS
isn't always available. It might be due to a server error or timeout (i
experience that on maybe 1% of page loads), or, as HTML rendering
capability extends to ever-smaller devices, a physical limitation.
span has no default
Ya'll, I hate to be rude, but isn't markup debates a little OT for CSS-d?
http://css-discuss.incutio.com/wiki/Off_Topic
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ
17 feb 2014 kl. 18:35 skrev Richard Grevers richard.grev...@gmail.com:
But if the differentiation
of such text matters, it makes sense to use markup that will differentiate
it regardless of the availability of CSS.
A valid point.
In most cases this is em or
strong, often with a class to
feb 17 2014 18:51 Micky Hulse mickyhulse.li...@gmail.com:
Ya'll, I hate to be rude, but isn't markup debates a little OT for CSS-d?
Actually it is indeed OT, except for where it ties in directly with CSS.
References to external discussions on the topic are not OT, IMHO.
So good point.
2014-02-17 19:35, Richard Grevers wrote:
It must be remembered that the presentation layer is optional, and CSS
isn't always available. It might be due to a server error or timeout (i
experience that on maybe 1% of page loads), or, as HTML rendering
capability extends to ever-smaller devices, a
Although the subject might immediately have people thinking about
Internet Explorer - and older versions, at that - in this case, it's
FireFox that appears to be the problem child.
The issue here is that even though the spec isn't necessarily clearly
defined, most browsers make a reasonable
Le 18 févr. 2014 à 10:06, Freelance Traveller edi...@freelancetraveller.com a
écrit :
The issue here is that even though the spec isn't necessarily clearly
defined, most browsers make a reasonable attempt at supporting
display:run-in. Firefox doesn't. Neither do older versions of IE, nor
On Mon, Feb 17, 2014 at 8:06 PM, Freelance Traveller
edi...@freelancetraveller.com wrote:
THE HTML
DL
DTJohn Jacob Jingleheimer Schmidt/DT
DDHis name is my name, too. Whenever we go out, we can hear the people
shout Hooray for John Jacob Jingleheimer Schmidt./DD
/DL
DESIRED RENDERING
On Mon, 17 Feb 2014 20:58:58 -0500, Jon Reece jon.re...@gmail.com
wrote:
I'm probably misunderstanding the question, but based on your pseudo-code
you could accomplish this with CSS 2.1 using display: inline:
Example: http://codepen.io/jreece/pen/yznEw
Actually, you _were_ misunderstanding the
25 matches
Mail list logo
