Re: [css-d] column help...
Philippe Wittenbergh wrote:
On Apr 29, 2011, at 11:24 PM, Alan Gresley wrote:
This is not completely true. Firstly the XHTML is traditional so
it's not true XHTML
That doesn't matter, as ID's starting with a leading digit are not
allowed in html4.01.
Right, but this is really a formality - though a validator message is
useful, as it makes the author suspicious. As far as HTML processing is
concerned, browsers don't seem to have problems with id values starting with
a digit, but they raise some issues in CSS.
The CSS selector is only valid when the (leading) digit is escaped…
Yes, and that makes CSS code somewhat messy, so it's usually best to avoid
id attribute values that start with a digit, if you intend to use them in
CSS.
IOW: #4col1 {background: lime;} is invalid (and correctly ignored by
browsers)
Yes.
but #\34col1 {background: lime;} is valid
Well, technically it is valid, but it does not match id=4col1. The reason
is that since c is a hexadecimal digit, 34c is taken as a hexadecimal
number. To make the selector match id=4col1, you can write it e.g. as
\34 col1
(i.e. with a space after 4).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] CSS positioning question
Try this:
#header {
height: 50px;
margin: 0 auto -19px;
padding: 30px 0 0;
position: relative;
text-align: center;
width: 445px;
background-color: white;
z-index: 100;
}
Regards,
Chetan Crasta
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] column help...
On 30/04/2011 12:53 PM, Philippe Wittenbergh wrote:
On Apr 29, 2011, at 11:24 PM, Alan Gresley wrote:
This is not completely true. Firstly the XHTML is traditional so
it's not true XHTML
That doesn't matter, as ID's starting with a leading digit are not
allowed in html4.01.
True. It's not allowed by the spec but that doesn't mean that this can't
be done. In the example that this thread is about, maybe it is wise just
to use 'col1' but many times in my own work it would have been easier if
I could have identified something just with digits or beginning with digits.
Beside, XHTML strict served as text/html is
handled just the same as html4.01 by browsers.
http://www.w3.org/TR/html401/types.html#type-name
I know. Pages with the bells and whistles
(content=application/xhtml+xml) are still served as text/html and
handled as html4.01 by browsers.
and secondly, IDs or classes beginning with a digit that is in an
escape sequence (flowed by one space of whitespace) is valid CSS.
The CSS selector is only valid when the (leading) digit is escaped…
IOW: #4col1 {background: lime;} is invalid (and correctly ignored by
browsers)
Correct.
but #\34col1 {background: lime;} is valid
This is incorrect since this is an identifier. It needs white-space. If
the HTML has this attribute,
id=2a
then it must be selected by this (with whitespace in between '2' and 'a').
#\32 a
A test.
http://css-class.com/test/temp/escape-ident-whitespace.xml
BTW, according to the validator, that document is invalid (4 Errors and
1 warning). The warning is solely due to my server settings. To stop
that warning, I must use the proper .xhtml extension.
http://css-class.com/test/temp/escape-ident-whitespace.xhtml
--
Alan Gresley
http://css-3d.org/
http://css-class.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] column help...
On Apr 30, 2011, at 3:19 PM, Jukka K. Korpela wrote:
That doesn't matter, as ID's starting with a leading digit are not
allowed in html4.01.
Right, but this is really a formality - though a validator message is useful,
as it makes the author suspicious. As far as HTML processing is concerned,
browsers don't seem to have problems with id values starting with a digit,
but they raise some issues in CSS.
My commenting on what HTML4.01 says was really nitpicking, in case you din't
notice :-p. Browser don't really care, afaik; and that is probably one reason
why HTML5 doesn't make ID's starting with a digit invalid.
The CSS selector is only valid when the (leading) digit is escaped…
Yes, and that makes CSS code somewhat messy, so it's usually best to avoid id
attribute values that start with a digit, if you intend to use them in CSS.
Sure, I wouldn't advocate it either; I can picture all those flashy web-apps
and friends though, with tons of script generated ID's. Even then, I would
recommend to prefix those ID's.
(on example: the Discuss commenting system attaches ID's to every possible
element. They do prefix them, afaict.)
but #\34col1 {background: lime;} is valid
Well, technically it is valid, but it does not match id=4col1. The reason
is that since c is a hexadecimal digit, 34c is taken as a hexadecimal
number. To make the selector match id=4col1, you can write it e.g. as
\34 col1
(i.e. with a space after 4).
Right, I intended to type that space there, obviously it didn't go beyond
intention. Blame the weather, or the wave, or something.
Philippe
--
Philippe Wittenbergh
http://l-c-n.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Footer placement in FF - FIXED!
On 30/04/2011 6:49 AM, Steve Caramia wrote:
Great! Thanks for cleaning up my code. I'm a little confused, though.
The Sticky Footer page specifically says NOT to add margin values on the
top and bottom.
If the div#wrap has overflow: hidden, then you can have child elements
with vertical margins. The div#wrap itself can not have vertical margins.
Using top and bottom margins inside some elements may push your footer
down by that margin height, perhaps in a header or the wrap or main
div's themselves.
See above.
Instead use padding to create spacing inside the
element. You'll notice this is happening if your page has little content
so that the footer should be on the bottom but you see that your window
scroll bar on the side indicates that it is sitting a bit below the
window bottom. Go find the offending top or bottom margin and switch it
to padding.
But it looks good now!
http://www.lankforddesign.com/
It still not a sticky footer. It's a footer that it always fixed at the
bottom of the viewport. To get this variant of footerStickAlt to work as
a sticky footer, change this CSS,
wrap {width: 960px;margin: 0 auto; min-height: 100%; }
^-- Note no # in your CSS.
#footer {
position: relative;
margin-top: -120px; /* negative value of footer height */
clear:both;
background:url(images_site/bg_footer.jpg) bottom repeat-x;
position:fixed; /* NOTE This causes the footer to be fixed in-respect
to the viewport */
height:120px;
/* width:100%; DELETE block elements are always 100% in width */
bottom: 0px; /* NOTE This is the offset that the footer has from the
bottom of the viewport */
/* display: block; DELETE block-level elements are always displayed as
blocks */
overflow:hidden;
}
to this CSS.
#wrap {
width: 960px;
margin: 0 auto;
min-height: 100%;
overflow: hidden; /* not needed if child elements don't have vertical
margins that can collapse into this element, safe to keep there */
}
#footer {
position: relative;
margin-top: -120px; /* negative value of footer height */
clear: both; /* this is needed if there is floating content such as a
side bar, safe to keep there */
background: url(images_site/bg_footer.jpg) bottom repeat-x;
border-bottom: 1px solid red; /* for testing, remove and adjust
height of footer */
height: 119px; /* for testing, remove and adjust height of footer to
height: 120px */
overflow: hidden; /* not needed if child elements don't have vertical
margins that can collapse into this element, safe to keep there */
}
--
Alan Gresley
http://css-3d.org/
http://css-class.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Footer placement in FF - FIXED!
On Sat, Apr 30, 2011 at 2:06 PM, Alan Gresley a...@css-class.com wrote:
It still not a sticky footer. It's a footer that it always fixed at the
bottom of the viewport. To get this variant of footerStickAlt to work as a
sticky footer, change this CSS,
That's right! I didn't notice it earlier.
In addition to the changes you suggested, here are some changes:
html, body {height: 100%;}
The article suggests this: !--[if !IE 7]
I haven't tested it in IE 9, but I think it has to be changed to
!--[if (IE 6) | (IE 8)
Regards,
Chetan Crasta
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] CSS, XML, HTML, valid or bogus was( column help)
On 30/04/2011 5:24 PM, Philippe Wittenbergh wrote:
On Apr 30, 2011, at 3:19 PM, Jukka K. Korpela wrote:
That doesn't matter, as ID's starting with a leading digit are
not allowed in html4.01.
Right, but this is really a formality - though a validator message
is useful, as it makes the author suspicious. As far as HTML
processing is concerned, browsers don't seem to have problems with
id values starting with a digit, but they raise some issues in
CSS.
I send bogus XHTML on all of my pages on CSS class which the validator
reports as valid XHTML (entitled to use a 'valid XHTML 1.0 icon').
A warning to those following this thread. Do not trust the validator.
Also, do not trust others on CSS discuss to know fully what they are
doing or talking about. Especially me since I'm mainly self learning.
Now to make this part of the thread on-topic for this list.
My commenting on what HTML4.01 says was really nitpicking, in case
you din't notice :-p. Browser don't really care, afaik; and that is
probably one reason why HTML5 doesn't make ID's starting with a digit
invalid.
Philippe. CSS just isn't to style HTML. It can style XML (and text/*
sub-types) and XHTML as well [1] [2].
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10
Digits are not forbidden in XML or XHTML.
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_8
The CSS selector is only valid when the (leading) digit is
escaped…
Yes, and that makes CSS code somewhat messy, so it's usually best
to avoid id attribute values that start with a digit, if you intend
to use them in CSS.
Sure, I wouldn't advocate it either; I can picture all those flashy
web-apps and friends though, with tons of script generated ID's. Even
then, I would recommend to prefix those ID's.
I see there use for tabular data (ie. databases) which can be script
generated.
but #\34col1 {background: lime;} is valid
Well, technically it is valid, but it does not match id=4col1.
The reason is that since c is a hexadecimal digit, 34c is taken
as a hexadecimal number. To make the selector match id=4col1, you
can write it e.g. as \34 col1 (i.e. with a space after 4).
Right, I intended to type that space there, obviously it didn't go
beyond intention. Blame the weather, or the wave, or something.
Philippe -- Philippe Wittenbergh http://l-c-n.com/
Digits are forbidden at the beginning of id and class selectors since
0~9, and a~f are reserved for hexadecimal notation. This is not because
you can't use CSS to select id and class selector beginning with digits,
since that would make CSS a little less powerful by only working with
HTML. The whitespaces are only needed in identifiers. In other parts of
CSS you can have whitespace or no whitepsace.
http://css-class.com/test/css21testsuite/rgb-colors-escaped-030.xht
I still don't understand why or how CSS can be parsed like this. I
theorized that this may be needed if some precessing of CSS code is
turned into escape sequences.
!DOCTYPE html
style type=text/css
\0064\0069\0076 { \0062\0061\0063\006B\0067\0072\006F\0075\006E\0064:
\006C\0069\006D\0065 }
/style
divThis division should have a lime background since the CSS represent
this codediv { background: lime }/code./div
[1] http://css-class.com/test/svg/svg-within-xhtml.xml
[2] http://onwebdev.blogspot.com/2010/12/linking-css-and-xml-documents.html
--
Alan Gresley
http://css-3d.org/
http://css-class.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] CSS positioning question
On Apr 30, 2011, at 2:24 AM, Chetan Crasta chetancra...@gmail.com wrote:
Try this:
#header {
height: 50px;
margin: 0 auto -19px;
padding: 30px 0 0;
position: relative;
text-align: center;
width: 445px;
background-color: white;
z-index: 100;
}
Regards,
Chetan
Thank you for the responses. I will work on this with the help you've given me.
Much appreciated!
Rory
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Borders oddity when page viewed in Chrome
Well, I expect quirks from IE, but I noticed the following problem today when I view my splash page in Google Chrome. The lower borders in the navigation box render normally, but all vertical and topmost borders are too light. I'm baffled. http://www.keithpurtell.com/kthings/chrome.png - Keith Purtell __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Borders oddity when page viewed in Chrome
On 1/05/2011 7:16 AM, Keith Purtell wrote: Well, I expect quirks from IE, but I noticed the following problem today when I view my splash page in Google Chrome. The lower borders in the navigation box render normally, but all vertical and topmost borders are too light. I'm baffled. http://www.keithpurtell.com/kthings/chrome.png - Keith Purtell Me too. The borders look the same in both FF 4 and Chrome 10 on Windows 7. -- Alan Gresley http://css-3d.org/ http://css-class.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Borders oddity when page viewed in Chrome
On May 1, 2011, at 6:16 AM, Keith Purtell wrote: I noticed the following problem today when I view my splash page in Google Chrome. The lower borders in the navigation box render normally, but all vertical and topmost borders are too light. I'm baffled. http://www.keithpurtell.com/kthings/chrome.png Interesting… Which OS is that ? And which version of Chrome ? Looking at the screenshot, the lower borders are rendered twice - once the expected color, once a lighter shade. Looks more like an issue with graphics rendering libs. it is like the borders are not painted hooked on the pixel grid (painted between 2 pixels). Does it changes if you resize the window slightly (making the width an even or odd number of pixels) ? #navigatex is set to have a width of 604px (even), but due to margin: auto, it doesn't always land exactly on the pixel grid, depending on the width of the parent blocks(s)/viewport. Each LI has a computed height of 109px (odd number !) on my system. (I can't repro the issue on OS X 10.6.7 nor on Ubuntu 11.04) I'm baffled. I'm not really. Looking at Chrome on Ubuntu 11.04 and 10.10, I see quite a few issues at the level of graphics rendering. All (very) small things (slightly distorted characters, uneven rounding in corners,…) but they add up quickly. I don't see those with Epiphany 2.31b, which also uses WebKit. That leads me to believe that those problems are in Chrome's Skia graphics rendering engine. Philippe -- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Borders oddity when page viewed in Chrome
On 4/30/11 5:16 PM, Keith Purtell wrote: Well, I expect quirks from IE, but I noticed the following problem today when I view my splash page in Google Chrome. The lower borders in the navigation box render normally, but all vertical and topmost borders are too light. I'm baffled. http://www.keithpurtell.com/kthings/chrome.png - Keith Purtell re: http://www.keithpurtell.com/kthings/index.htm Keep it simple. Best, Studs T. Division Street Chicago PS Easier said than done :-) . -- http://chelseacreekstudio.com/ http://chelseacreekstudio.com/fa/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
