Re: [css-d] Extending border to height of tallest column.

[David Hucklesby]

On 7/31/12 8:16 PM, J.C. Berry wrote:

Hi everyone, I have a layout that has three columns with two of them of
varying heights, i.e. one is taller than the other. I need to have a 1
pixel border extend to the height of the taller of the two columns. Any
directions or tutorials would be welcome. I would like to also learn
this as compared to just getting an answer. Thanks so much!



"One is taller than the other."--Do you mean three columns, each of
differing height? If so, and you don't need to support Internet Explorer
earlier than version 8, perhaps this might work for you -

 

Hope so. View source to see all the code. CSS embedded in the .
--
Cordially,
David
__
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] collapsed border table issue

[Jukka K. Korpela]

2012-08-01 4:38, John wrote:


Given this code:

table, th, td{
border:1px dotted black;
border-collapse:collapse;
}

I find that when I use colspan="x", some of the borders are solid as a result, 
perhaps because they're doubled up as cells are widened by colspan.


1px dotted border has always been problematic, but this a new oddity. It 
seems to be a bug in WebKit browsers (Chrome, Safari). At least my test, 
http://www.cs.tut.fi/~jkorpela/test/coll.html, shows such a phenomenon 
on them but not on other browsers. The markup in my test is



foobarstuff1more
humspanningmore
foobarstuff2more


and on WebKit browsers, the border below stuff1 and above stuff2 is 
solid, in default (100%) zoom. When the zoom is changed (e.g. with Ctrl 
+), the border turns to dotted, then on new zooming to solid again. 
Strange. Tested on Win 7. I took a screen capture and zoomed, and the 
border is completely black, as opposite to letters, which exhibit color 
variation due to subpixel rendering.



Is there a way around this, such that all the lines are 1px dotted black 
regardless of how I use colspan?


A clumsy workaround, simulating collapsing borders with separate borders 
(won't work on IE 6 due to lack of sufficient CSS support, so you might 
add a "conditional comment" that switches to using your original code on 
IE):


table {
border-collapse: separate;
border-spacing: 0;
 }
th, td {
border: 1px dotted black;
border-top-width: 0;
border-left-width: 0;
 }
 tr:first-child > th, tr:first-child > td {
border-top-width: 1px;
 }
th:first-child, td:first-child {
border-left-width: 1px;
 }

(It just draws borders around each cell so the cells have no adjacent 
borders.)


Yucca


__
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] on html and css versions

[Jukka K. Korpela]

2012-08-01 4:16, Georg wrote:


On 01.08.2012 00:14, Tedd Sperling wrote:


This works for me, my students, and W3C validation:

---

  
  
  
  


Since that only contains an HTML5 "standards mode" trigger (for better
than v.5.5 CSS support in IE/win *) and no DTD to check markup variant
against, it might be interesting for the OP to know what standard the
rest of the markup is actually coded in accordance with.


The “standards mode” trigger (or lack thereof) is all that matters from 
the CSS perspective. It drastically affects the level of CSS support and 
CSS interpretation, especially on IE.


The HTML5 doctype implies HTML5 syntax, for the purposes of the W3C 
Markup Validator and validator.nu.



HTML 4.01 Strict, XHTML 1.0 Strict served as HTML, and markup containing
new HTML5 elements, will all work and pass existing HTML5 validators,


No, there are constructs that are valid in HTML 4.01 Strict and XHTML 
1.0 Strict but trigger error messages in experimental software called 
HTML5 validators, as the constructs do not conform to HTML5 drafts. For 
example,  and , or width attribute in . In HTML5 thinking, 
you are supposed to replace them with CSS. But they still work in 
browsers no matter what doctype you use.



but the result won't necessarily be the same in all browser versions the
OP want to support without including some extra steps/info.


Nothing can ensure that the result will necessarily be the same. But I 
have no idea of what specific point you are referring to here.


Yucca


__
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] Extending border to height of tallest column.

[Al Sparber]

On 7/31/2012 11:16 PM, J.C. Berry wrote:

Hi everyone,
I have a layout that has three columns with two of them of  varying
heights, i.e. one is taller than the other. I need to have a 1 pixel border
extend to the height of the taller of the two columns. Any directions or
tutorials would be welcome. I would like to also learn this as compared to
just getting an answer. Thanks so much!



In this day and age, the safest and simplest way to do it is with a 
CSS-driven script:


http://www.projectseven.com/tutorials/css/pvii_columns/

The tutorial can be done and the script used without Dreamweaver.

--
Al Sparber - PVII
http://www.projectseven.com
The Finest Dreamweaver Menus | Galleries | Widgets
Since 1998

__
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] Extending border to height of tallest column.

[J.C. Berry]

Hi everyone,
I have a layout that has three columns with two of them of  varying
heights, i.e. one is taller than the other. I need to have a 1 pixel border
extend to the height of the taller of the two columns. Any directions or
tutorials would be welcome. I would like to also learn this as compared to
just getting an answer. Thanks so much!

-- 
J.C. Berry, M.A.
UI Developer
619.306.1712(m)
jcharlesbe...@gmail.com
portfolio: http://www.mindarc.com


This E-mail is covered by the Electronic Communications Privacy Act, 18
U.S.C. ?? 2510-2521 and is legally privileged. This information is
confidential information and is intended only for the use of the individual
or entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.

__
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] IE9 stacking opacity bug. Any real solutions?

[Georg]

On 01.08.2012 03:37, Alan Gresley wrote:
I would most certainly need a reduced test case. I remember your 
multi-layer templates from the past. I did have a look and a play 
around and I also checked the latest spec [1] and saw the below words. 
I not even sure if IE9 is doing it wrong.


Well Alan, since the 'absolute positioned generated content faux column' 
isn't layered out of order - no z-index on it or the element it is 
generated ::before, and only IE9 reorder/stack it to end up above an 
element later in the source-code that isn't layered out of order - no 
z-index there either, I can't help but think IE9 got it wrong. Otherwise 
all other browsers must have gotten it wrong.


May create a reduced test case later, but generally I don't believe 
reduced cases tell much in cases like mine since they will inevitably 
only focus on a limited number of factors behind browsers' behavior. 
Complex cases reveal most browser weaknesses.


Only difference from my older templates is that this one makes extended 
use of positioned generated content for "visuals" to avoid cluttering up 
source-code. Have already found a whole series of IE9 bugs related to 
generated content, and this may just be another one.



1. http://dev.w3.org/csswg/css3-color/#transparency


regards
Georg

__
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] collapsed border table issue

[John]

Given this code: 

table, th, td{
border:1px dotted black;  
border-collapse:collapse;
}

I find that when I use colspan="x", some of the borders are solid as a result, 
perhaps because they're doubled up as cells are widened by colspan.

Is there a way around this, such that all the lines are 1px dotted black 
regardless of how I use colspan?

Thank you!

John
__
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] IE9 stacking opacity bug. Any real solutions?

[Alan Gresley]

On 31/07/2012 5:34 PM, Georg wrote:

Apparently not.

 Georg



I would most certainly need a reduced test case. I remember your 
multi-layer templates from the past. I did have a look and a play around 
and I also checked the latest spec [1] and saw the below words. I not 
even sure if IE9 is doing it wrong.


  | Since an element with opacity less than 1 is composited
  | from a single offscreen image, content outside of it
  | cannot be layered in z-order between pieces of content
  | inside of it. For the same reason, implementations must
  | create a new stacking context for any element with
  | opacity less than 1. If an element with opacity less
  | than 1 is not positioned, implementations must paint
  | the layer it creates, within its parent stacking context,
  | at the same stacking order that would be used if it were
  | a positioned element with ‘z-index: 0’ and ‘opacity: 1’.
  | If an element with opacity less than 1 is positioned,
  | the ‘z-index’ property applies as described in [CSS21],
  | except that ‘auto’ is treated as ‘0’ since a new stacking
  | context is always created.




1. http://dev.w3.org/csswg/css3-color/#transparency




--
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] on html and css versions

[Georg]

On 01.08.2012 00:14, Tedd Sperling wrote:


This works for me, my students, and W3C validation:

---

  
  
  
  




Since that only contains an HTML5 "standards mode" trigger (for better 
than v.5.5 CSS support in IE/win *) and no DTD to check markup variant 
against, it might be interesting for the OP to know what standard the 
rest of the markup is actually coded in accordance with.
HTML 4.01 Strict, XHTML 1.0 Strict served as HTML, and markup containing 
new HTML5 elements, will all work and pass existing HTML5 validators, 
but the result won't necessarily be the same in all browser versions the 
OP want to support without including some extra steps/info.


regards
Georg

* http://www.gunlaug.no/contents/wd_additions_34.html
...and more recently: 
http://www.gunlaug.com/contents/design/applying_html5_today.html

__
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] on html and css versions

[Tedd Sperling]

On Jul 31, 2012, at 4:18 PM, John D  wrote:

>> What html dtd is recommended to reach the most users? HTML 4.01
>> Transitional -- and CSS2?

This works for me, my students, and W3C validation:

---

 
 
 
 

Your title

 
 
 


 

---

Cheers,

tedd


_
t...@sperling.com
http://sperling.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/

[css-d] Does TextWrangler ever get "weird?"

[John]

Has anyone ever experienced problems with names within code using TW on OS X?

I just had a case where I created something for which there's a right and a 
left part of a food menu. I did the left part, duped the markup and CSS, 
changed all relevant things which were "left" to "right" and the markup acted 
as though it didn't see the div containing it.

After SERIOUS looking at my code, I saw no problem, then decided to change the 
name of  "#menuRight" to the new name of  "#menuRighto" and as if by magic, the 
page was then correct when viewed in a browser.

I assumed I had a duplicate name, or a very similar name in my CSS, but there's 
only one.  And just now, I changed my #name and the div name in the markup to 
the name which previously didn't work: #menuRight, and that works where it 
formerly had not.

Any thoughts on this?

Thank you!

John
__
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] on html and css versions

[John D]

> What html dtd is recommended to reach the most users? HTML 4.01
> Transitional -- and CSS2?
> 

I use this as my starting point for all my pages these days:






Untitled 1








Good luck.

  
__
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] font-size: 62.5% revisited

[Hakan Kirkan]

How about using terms like  (small, x-small, xx-small, medium, large,
x-large or xx-large).  Can it be an alternative to % ?

Thanks
Hakan Kirkan
Dominor LLC/ Miami
http://dominor.com

On Thu, Jul 26, 2012 at 12:06 AM, David Hucklesby wrote:

> Taking Richard Rutter's original idea to make the base font-size 62.5%,
> which translates to 10px on most desktop computers running at the common 96
> DPI setting, I suggest a modern alternative. It looks like this:
>
> html { font-size: 125%; }
>
> Georg has a nice write-up explaining the problem with 62.5%--
>  
> 
> >
>
> Yes, I'm using a nominal 20px for equally easy conversion. But wait,
> there's
> more!
>
> For the majority of text on a page to display at 16px I'd use a font-size
> of
> 80% on the BODY element. For 18px I'd use 90%[1].
>
> Today, nearly all browsers understand REM units. They are relative to the
> root (HTML) size of (nominal) 20px. Easy-peasy; fewer fractions, and no
> problems with cascading percentages.
>
> For the rest--IE 8 and earlier, and Opera Mini, keywords should work well
> enough, since you won't get "pixel perfection" on those browsers
> anyway--whatever that might mean. IE will re-size text set with keywords,
> but not with pixels.
>
> Perhaps this is just nonsense. But it just has to be better than 62.5%. I
> use Opera a lot, with a minimum text size of 12px--you'd be surprised how
> many sites break because of the scaling due to the 62.5% base size. It's
> everywhere! :(
>
>  [1] Taking a partial leaf out of Jeffrey Zeldman's blog design here.
> --
> Cordially,
> David
> __**__**__
> 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-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] font-size: 62.5% revisited

[Jukka K. Korpela]

2012-07-31 21:04, Josh Rehman wrote:


Well, I honestly don't understand where you see an ambiguity. So,
you're either using physical units like cm or mm or pixels, in which
case you're using an angular measure.


No, in situations where "these dimensions" (all so-called absolute 
length units, including px) are anchored to "physical measurements", so 
that e.g. 1in is really the physical inch, then the px unit is 
absolutely 0.2648333... millimeters (25.4 mm divided by 96).


The point is that CSS3 defines, following browser practice, the units so 
that 1in = 96px (so either the meaning of "in" or the meaning of "px" 
has to adjust according to the "anchor unit").


Yucca


__
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] Media query workflow across multiple files...

[Micky Hulse]

Hi!

On Tue, Jul 31, 2012 at 5:26 AM, Tom Livingston  wrote:
> Pro help? Where? ;-)

Pro, and modest too! :D

> Here's an example of the code from the head of the document I usually
> start from:

Awesome! Thanks Tom, that's very helpful :)

This will keep me busy for the next few days (at least).

Have a great day!

Cheers,
Micky
__
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] font-size: 62.5% revisited

[Josh Rehman]

On Tue, Jul 31, 2012 at 10:51 AM, Jukka K. Korpela  wrote:
> 2012-07-31 20:43, Josh Rehman wrote:
>
>>> The reality is different from the spec, as one can see from the
>>> discussion of the topic in the relevant CSS3 draft:
>>> http://www.w3.org/TR/css3-values/#absolute-lengths
>>> The px unit may relate to the so-called reference pixel, or it may be
>>> anchored to a physical unit (1/96 of an inch, when "inch" really means an
>>> inch, 25.4 mm).
>>
>>
>> Well, no. I re-read the spec and found no mention of an ambiguity.
>
>
> It's right in the main text there:
>
> "For a CSS device, these dimensions are either anchored (i) by relating the
> physical units to their physical measurements, or (ii) by relating the pixel
> unit to the reference pixel. For print media and similar high-resolution
> devices, the anchor unit should be one of the standard physical units
> (inches, centimeters, etc). For lower-resolution devices, and devices with
> unusual viewing distances, it is recommended instead that the anchor unit be
> the pixel unit. For such devices it is recommended that the pixel unit refer
> to the whole number of device pixels that best approximates the reference
> pixel."

Well, I honestly don't understand where you see an ambiguity. So,
you're either using physical units like cm or mm or pixels, in which
case you're using an angular measure. Since we aren't talking about
physical units in this thread, there is no ambiguity. Your statement
"The reality is different from the spec" doesn't seem to have any
supporting evidence.
__
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 drop shadow on border

[Tom Livingston]

On Tue, Jul 31, 2012 at 12:20 PM, Dave Solko  wrote:
> I have a 1px tool line at the bottom of a div. Is it possible to make a 
> narrow drop shadow using 'box-shadow'? Everything I've been able to come up 
> with is the height of the div. Ideally, I'd like something about 5px tall 
> with the blur.
>
> TIA
>
>
> Dave Solko


Can you add another element to the bottom of the div and add a shadow
to that, or use div:after to do it?


-- 

Tom Livingston | Senior Interactive Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.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] font-size: 62.5% revisited

[Jukka K. Korpela]

2012-07-31 20:43, Josh Rehman wrote:


The reality is different from the spec, as one can see from the discussion of 
the topic in the relevant CSS3 draft:
http://www.w3.org/TR/css3-values/#absolute-lengths
The px unit may relate to the so-called reference pixel, or it may be anchored to a 
physical unit (1/96 of an inch, when "inch" really means an inch, 25.4 mm).


Well, no. I re-read the spec and found no mention of an ambiguity.


It's right in the main text there:

"For a CSS device, these dimensions are either anchored (i) by relating 
the physical units to their physical measurements, or (ii) by relating 
the pixel unit to the reference pixel. For print media and similar 
high-resolution devices, the anchor unit should be one of the standard 
physical units (inches, centimeters, etc). For lower-resolution devices, 
and devices with unusual viewing distances, it is recommended instead 
that the anchor unit be the pixel unit. For such devices it is 
recommended that the pixel unit refer to the whole number of device 
pixels that best approximates the reference pixel."


Yucca


__
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] font-size: 62.5% revisited

[Josh Rehman]

On Tue, Jul 31, 2012 at 12:07 AM, Jukka K. Korpela  wrote:
>
> 2012-07-31 3:32, Josh Rehman wrote:
>
>> The screen resolution thing is a non-issue because the CSS px
>> is defined to be an angular measure:
>
>
> The reality is different from the spec, as one can see from the discussion of 
> the topic in the relevant CSS3 draft:
> http://www.w3.org/TR/css3-values/#absolute-lengths
> The px unit may relate to the so-called reference pixel, or it may be 
> anchored to a physical unit (1/96 of an inch, when "inch" really means an 
> inch, 25.4 mm).


Well, no. I re-read the spec and found no mention of an ambiguity. A
pixel is defined assuming 96dpi and is an angular measure. From the
URL you cite:

"The reference pixel is the visual angle of one pixel on a device with
a pixel density of 96dpi and a distance from the reader of an arm's
length. For a nominal arm's length of 28 inches, the visual angle is
therefore about 0.0213 degrees. For reading at arm's length, 1px thus
corresponds to about 0.26 mm (1/96 inch)."

The spec goes on to give examples of converting reference pixels into
real pixels.
__
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] css drop shadow on border

[Dave Solko]

I have a 1px tool line at the bottom of a div. Is it possible to make a narrow 
drop shadow using 'box-shadow'? Everything I've been able to come up with is 
the height of the div. Ideally, I'd like something about 5px tall with the blur.

TIA


Dave Solko
Pixel Alchemy
d...@pixelalchemy.com
513.300.2165



__
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] Media query workflow across multiple files...

[Tom Livingston]

On Tue, Jul 31, 2012 at 12:32 AM, Micky Hulse
 wrote:
> Thanks a bunch Tom, that's very helpful info. I really appreciate the
> pro help! :)
>
> I'm going to play with workflow ideas you mention.
>
> I'll probably be back with more questions... For now, have a nice night.
>
> Cheers,
> Micky


Pro help? Where? ;-)

Here's an example of the code from the head of the document I usually
start from:





























HTH

-- 

Tom Livingston | Senior Interactive Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.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] on html and css versions

[Georg]

On 31.07.2012 10:59, Gergely Buday wrote:

What html dtd is recommended to reach the most users? HTML 4.01
Transitional -- and CSS2?


Markup: the Stricter the better. Markup in accordance with HTML 4.01 
Strict works fine in around 99.99% of browsers _in use_ today.
HTML5  using new elements may fail in a few old browsers, in old IE 
because users of obsolete browsers may also block script-support and 
take other "protective measures" that prevents it from working.


CSS: make note of the few differences between CSS2 and CSS2.1, as same 
code may be treated in different ways in old and new browser versions. 
Apart from that there is no definitive answer, since lack of support, 
bugs and weaknesses will keep you looking for answers in actual browser 
versions for every few lines of CSS code you put in no matter what CSS 
version(s) you choose to stick to - or rather which browser versions you 
choose to support.


Most of us apply, and test with, CSS from all versions while designing 
in/for new browsers, and accept "graceful degradation", and sometimes 
"less graceful degradation" or right out "disgraceful degradation" in 
older browsers. This to avoid being stuck with CSS that worked in most 
browsers over a decade ago, and no way out and into the future.


No complete set from any CSS "version" will work perfect or in the same 
way in all browser versions released the last 15 years anyway. Even 
latest browser versions differ in how they interpret CSS standards and 
still can and do claim conformance, partly because not all points in 
standards are described as clearly as they should be, but also because 
they have adjusted to various more or less wide-spread coding habits 
over the years.


So, depending on whether you want to go forward with CSS, or stop at 
some point in time where you feel it is "safer", you still have to check 
the result in all browser versions you want to secure support for and 
maybe add workarounds for rendering differences. No way around "testing".


regards
Georg
__
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] on html and css versions

[Gergely Buday]

Hi there,

this is not strictly a css question but closely related.

What html dtd is recommended to reach the most users? HTML 4.01
Transitional -- and CSS2?

- Gergely
__
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] IE9 stacking opacity bug. Any real solutions?

[Georg]

Apparently not.

Georg
__
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] font-size: 62.5% revisited

[Jukka K. Korpela]

2012-07-31 3:32, Josh Rehman wrote:


The screen resolution thing is a non-issue because the CSS px
is defined to be an angular measure:


The reality is different from the spec, as one can see from the 
discussion of the topic in the relevant CSS3 draft:

http://www.w3.org/TR/css3-values/#absolute-lengths
The px unit may relate to the so-called reference pixel, or it may be 
anchored to a physical unit (1/96 of an inch, when "inch" really means 
an inch, 25.4 mm).


Yucca

__
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/